1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for run-time translation of legacy Emulator High Level Language Application Programming Interface (EHLLAPI) calls into object-based calls. Using the present invention, there is no need to rewrite or restructure existing application code which invokes procedurally-oriented EHLLAPI calls to access a host presentation space. Instead, the calls are translated automatically into calls that use an object-oriented host access interface.
2. Description of the Related Art
One of the challenges facing information services (xe2x80x9cISxe2x80x9d) professionals today is the difficulty of bridging legacy mainframe host data to modern user interfaces. Most legacy host applications present their data in text-based user interfaces designed for use on specific, obsolete character-based terminals. The legacy applications were written with this character-based terminal presentation space as the only interface format in which the host data output is created, and in which host data input is expected. xe2x80x9cPresentation spacexe2x80x9d is a term used abstractly to refer to the collection of information that together comprises the information to be displayed on a screen, as well as the control data that conveys how and where that information is to represented. This collection of information is stored in an area of computer storage and/or memory.
A typical character-based terminal is the IBM Model 3270. (IBM is a registered trademark of the International Business Machines Corporation.) This terminal model was designed to display information in a matrix of characters, where the matrix consisted of 24 rows each having 80 columns. When programs were written expecting this display format, programmers would specify placement of information on the screen using specific row and column locations. Information formatted for this display is sent as a xe2x80x9cdata streamxe2x80x9d to the mechanism in the display hardware that is responsible for actually displaying the screen contents. The phrase xe2x80x9cdata streamxe2x80x9d refers to the fact that the data is sent as a linear string, or stream, of characters. This stream of characters contains both the actual textual information to be displayed on the screen, as well as information specifying where and how the text is to be displayed. xe2x80x9cWherexe2x80x9d consists of the row and column where the text is to begin, and xe2x80x9chowxe2x80x9d consists of a limited number of presentation attributes such as what color (typically either green or white) to use when displaying that text. While the Model 3270 is a specific type of IBM display hardware, data formatted for any display having similar characteristics became a de facto standard format referred to as a xe2x80x9c3270 data streamxe2x80x9d. Similarly, the IBM Model 5250 is another type of character-based terminal. This terminal displays data in a slightly different manner from the IBM 3270, and consequently uses a different data stream format. The xe2x80x9c5250 data streamxe2x80x9d also became a de facto standard format for displays having similar characteristics. A third type of data stream format commonly used by legacy host applications is referred to simply as an xe2x80x9cASCII data streamxe2x80x9d. While an ASCII data stream is not formatted for a specific model of display screen, a data stream in this format has certain predefined characteristics (for example, the manner in which a control character indicates the line spacing to be used).
The displays used with modern computer workstations (including personal computers, network computers, etc.) support graphics and video, in addition to text characters. These displays do not use a character-based row and column matrix approach to screen layout. Instead, the programmer has access to thousands of tiny display elements, allowing the various types of information to be placed virtually anywhere on the display screen.
When the modem computer workstation is used to access a legacy host application running on a mainframe, the output data created by that host application is often still formatted as one of the character-based data streams. The workstation (whether it is a personal computer, network computer, or other type of computer) has access to the host application and the presentation space it uses through mainframe emulator software. An example of mainframe emulator software is the Personal Communications product from IBM. Emulator software runs on the workstation. This software provides facilities to establish a telecommunications connection between the workstation and the host computer, to invoke execution of a software application stored on that host, and to transfer information between the host application and the workstation as the application runs. When a legacy application is accessed using an emulator, it appears to the legacy application as if it was interacting with a so-called xe2x80x9cdumb terminalxe2x80x9d, instead of an intelligent workstation. The emulator takes care of reformatting the character-based data sent by the legacy application (i.e. using the presentation space to transfer screen data), for display on a modern display screen.
Currently, there is movement in the computer information industry away from using mainframe emulators as the primary user interface to the host applications. Therein lies the problem. When an emulator is no longer used, the emulator""s complicated interface logic for translating between the character-based data stream and the modem workstation display screen layout must be performed by some other service.
One solution to this problem is to rewrite the host applications, so that they create their output in a format recognized by modern displays. For most companies, this rewrite of host applications represents a monumental task. Not only are there literally millions of lines of code to rewrite, the skills that are required to program host applications (ability to use the COBOL programming language, for example) are in short supply.
There is an alternative solution to rewriting the host applications, which many IS professionals have chosen. The user interface facilities of many modern application programs accept the existing host presentation space format when retrieving data from the host application, but do not show the data to the user in this format. The new user interface facilities perform a xe2x80x9cscreen scrapingxe2x80x9d process, where data is extracted from the host presentation space, and present this scraped data to the user in a form that is appropriate for the modern display screen device. By convention, this form tends to be a graphical user interface where information is presented in a window-based layout. The user interacts with the application using this graphical user interface. When data needs to be returned to the application, for example in response to the user""s input, the user interface facility converts this information automatically into a format that is recognized by the host application.
IBM""s Emulator High Level Language Application Programming Interface, or xe2x80x9cEHLLAPIxe2x80x9d, was one of the first screen scraping application programming interfaces. EHLLAPI provides an application program with an interface to the presentation space with which legacy applications expect to exchange screen data. This interface has been implemented in a variety of software products, and by many different software vendors. One example of a product using this EHLLAPI interface is IBM""s Personal Communications emulator product. EHLLAPI has been available for use for a number of years, and has become a de facto standard for screen scraping. Consequently, there is a great deal of application code in use today which uses EHLLAPI.
EHLLAPI is a procedural interface, and is well-suited for procedural programming languages such as the C programming language. Recently, however, developers have been presented with new object-oriented APIs that better model interaction with a legacy host screen. These new APIs are better suited for use with object-oriented programming languages than is EHLLAPI. One example of the new object-oriented APIs is the eNetwork Host Access Class Library (xe2x80x9cHACLxe2x80x9d) from IBM. HACL provides programming access to 3270, 5250, and Virtual Terminal (xe2x80x9cVTxe2x80x9d) data streams. Another example of an object-oriented API is the pending Open Host Interface Object (xe2x80x9cOHIOxe2x80x9d) standard under development by the Internet Engineering Task Force (xe2x80x9cIETFxe2x80x9d). (Information on HACL can be found on the World Wide Web at www.sofware.ibm.com/network/technology/hacl, and the draft OHIO standard can be found at http://www.ietf.org/internet-drafts/draft-ietf-tn3270e-ohio-00.txt.) Both HACL and OHIO provide an easier-to-use, more robust methodology for host screen input and output. These object-oriented APIs have facilitated construction of products such as IBM""s Host on Demand, in which the EHLLAPI interface cannot be supported due to syntactic differences in object-oriented programming languages and their inherent event-driven nature. Because EHLLAPI is procedurally-oriented, while the new interfaces use an object model, changing existing application programs from use of EHLLAPI to use of an object-oriented interface such as HACL or OHIO could involve significant source code changes and program restructuring. This type of change would be very expensive in terms of programming effort, and would require a considerable amount of time to implement and test. In addition, the source code for the EHLLAPI applications may no longer be available. Further, the programming skills needed for rewriting EHLLAPI applications to use OHIO or HACL (that is, programmers skilled in EHLLAPI and OHIO or HACL) are in short supply.
Accordingly, what is needed is a technique whereby existing applications using EHLLAPI function calls can take advantage of object-oriented host access interfaces, without requiring a rewrite or restructuring of the existing EHLLAPI application.
An object of the present invention is to provide a technique whereby application programs using EHLLAPI function calls are able to efficiently interact with legacy host application data using an object-oriented host access interface.
Another object of the present invention is to provide a technique whereby these EHLLAPI application programs can interact with the legacy host application data using an object-oriented host access interface without rewriting the workstation EHLLAPI application.
A further object of the present invention is to provide this technique through automated translation from EHLLAPI calls to object-oriented method invocations.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer-readable code for use in a computing environment having a connection to a network, for run-time translation of Emulator High Level Language Application Programming Interface (EHLLAPI) function calls to object-oriented host access calls. This technique comprises: creating a session object for a host-connected session to be used for an EHLLAPI application; receiving an EHLLAPI function call from the application; determining a sub-function requested by the function call; determining zero or more method invocations corresponding to the sub-function; performing the method invocations; and returning a single result of the method invocations to the application. Further, the EHLLAPI application uses a sequential procedural model, and the technique further comprises converting the sequential procedural model to an event-driven object-oriented model used by the object-oriented host access calls. The object-oriented host access calls may be those defined in a Host Access Class Library (HACL) specification, those defined in an Open Host Interface Object (OHIO) specification, or those defined in an alternative specification. The technique preferably further comprises creating and initializing a program control block for the application, and creating and initializing a session control block for the session object. In addition, the session object preferably further comprises a presentation space object and an operator information area object, and performing the method invocations preferably further comprises invoking the zero or more determined method invocations on zero or more of the session object, the presentation space object, and the operator information area object.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.